Relational database management systems (RDBMS) have been in wide use for decades. Relational databases have a number of characteristics that have led to their widespread use, especially for transaction processing systems. Such characteristics include the well-known support for ACID properties (atomicity, consistency, isolation and durability), as well as the backing of well-established vendors with a vast knowledge base and sophisticated tool sets that are useful in resolving many types of problems fairly quickly. A common technique for accessing and manipulating RDBMS data is to use SQL (Structured Query Language), a special purpose programming language designed for relational systems. The use of SQL is so widespread that it has almost become the default language for specifying database-related operations. Furthermore, the representation of data in the form of relational tables, in which each row has the same set of columns, is the data model that is most familiar to both IT (Informational Technology) technical professionals and business users.
More recently, and especially as the rate of data acquisition from such sources as web server logs or sensors has grown rapidly and exposed some scalability problems of relational databases, a number of non-relational approaches to data management have gradually stared becoming more popular. Some of these approaches are collectively referred to as “NoSQL” databases, as they typically do not rely on SQL as their query language. Instead of using SQL, different non-relational database vendors have tended to use custom languages and interfaces. Many recent non-relational database systems typically promise excellent write performance, as well as distributed and fault-tolerant architectures designed to overcome some of the perceived shortfalls of traditional RDBMSs. These benefits are often achieved at the cost of relaxing some of the ACID constraints that are strictly enforced by RDBMSs.
In practice, the write performance of at least some non-relational databases indeed appears to be superior, at least with respect to equivalently-priced commercial relational database systems. However, as is often the case when a new type of technology begins to gain acceptance, the use of non-relational database systems has uncovered its own set of problems. For example, read performance often lags behind write performance in non-relational systems. A lack of standardization with respect to query languages for non-relational databases is another frequently-cited limitation. Tools to allow business users to analyze, understand and make use of the collected non-relational data easily have also yet to mature.
While embodiments are described herein by way of example for several embodiments and illustrative drawings, those skilled in the art will recognize that embodiments are not limited to the embodiments or drawings described. It should be understood, that the drawings and detailed description thereto are not intended to limit embodiments to the particular form disclosed, but on the contrary, the intention is to cover all modifications, equivalents and alternatives falling within the spirit and scope as defined by the appended claims. The headings used herein are for organizational purposes only and are not meant to be used to limit the scope of the description or the claims. As used throughout this application, the word “may” is used in a permissive sense (i.e., meaning having the potential to), rather than the mandatory sense (i.e., meaning must). Similarly, the words “include,” “including,” and “includes” mean including, but not limited to.